@alex-frankel — first, thanks for your patience and for the clear feedback on the previous round of PRs (#14739, #14740, #14741, #14742). Your write-up of the new testResult requirement was exactly what I needed.

This PR follows the contribution-guide workflow:

• Updated main.bicep was deployed locally against my subscription before the PR was opened.
• metadata.json carries validationType: "Manual" and a testResult.deployments block with the real correlationId and deploymentName from that deployment.
• I also rebased the branch onto current master so the diff is the minimal one-line bicep change + the corresponding regenerated azuredeploy.json + the metadata.json update (no longer showing azuredeploy.json as a new file — that was a fork-staleness artifact in the original push).

Ready for review / /verify whenever you have a moment. Thanks again!

@msmbaldwin - check this PR for updates that may be needed to documentation that references this sample. [This is an automated message. You are receiving it because you are listed as the docOwner in metadata.json.]

/validate

🤖 Quickstart Sample Summary

Sample Summary

• This sample creates an Azure Key Vault with Azure RBAC authorization enabled.
• It creates a cryptographic key stored inside the Key Vault.
• The deployment now enables purge protection on the Key Vault to prevent accidental or malicious deletion.

Resources Deployed

• Microsoft.KeyVault/vaults (defined in both main.bicep and azuredeploy.json): Deploys the Azure Key Vault with properties such as RBAC authorization, soft delete enabled with 90 days retention, and purge protection enabled.
• Microsoft.KeyVault/vaults/keys (defined in both main.bicep and azuredeploy.json): Creates a cryptographic key inside the Key Vault with parameters controlling key type, size, permitted operations, and curve name.

Security Findings

• Multiple high-severity findings around Key Vault network security:
  • AZR-000355 (Template Analyzer): Key Vault accepts connections from any network by default; recommends changing the default action from 'Allow' to 'Deny' and configuring firewall rules.
  • CKV_AZURE_189 (Checkov): Azure Key Vault should disable public network access.
  • CKV_AZURE_109 (Checkov): Ensure firewall rule settings are enabled for Key Vault.
  • CKV_AZURE_40 (Checkov): Ensure that expiration dates are set on all keys.
• Medium-severity finding:
  • AC_AZURE_0169 (Terrascan): Logging for Azure Key Vault should be enabled.
• Low-severity findings:
  • CKV_AZURE_112 (Checkov): Ensure Key Vault key is backed by HSM.
• Additional notes: The template currently allows connections from any network by default (networkAcls defaultAction is 'Allow'), which is a security risk that should be addressed by restricting network access. No explicit expiration date is set on the created key which is a recommended security practice.

Key Parameters

• vaultName: Name of the Key Vault to be created.
• keyName: Name of the cryptographic key to create inside the vault.
• location: Azure location for the resources (default is resource group location).
• skuName: SKU of the Key Vault (standard or premium).
• keyType: Type of key to create inside the vault (e.g., RSA, EC).

Notes for Reviewers

• The PR enables purge protection on the Key Vault, improving security against accidental deletion.
• The template currently does not restrict network access to the Key Vault, which triggers multiple high-severity security scanner warnings.
• No expiration date is configured on the key, another security best practice missing.
• The README and metadata.json provide basic descriptive information but do not mention purge protection explicitly.
• Consider adding network ACL rules and key expiration policies for improved security.

Files Touched

• azuredeploy.json
• main.bicep
• metadata.json

Generated by the quickstart summarizer agent (v2 — agentic + MSDO security) · triggered by /validate